feat: one-key client for the new private key - #137

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 851a0b7. Configure here.}

There's also a .netrc case in _BearerTrackClient: setting session.auth = None lets Requests replace the supplied Bearer header with Basic auth if there's a matching entry for the API host. Could we use an explicit Bearer auth handler and cover that with a prepared-request check? It only happens with that matching entry, but we'd still be sending different credentials from the ones the caller passed.

Two smaller wording follow-ups: 401/403 can also mean an IP restriction or a disabled workspace, so “this key can't…” is a bit too specific. And the README should qualify legacy-key support: transactional calls work, but Bearer Track calls on Pipelines workspaces need a source-bound new key.

I'd like us to sort out the URL handling in the existing thread and this auth case before merging. That's my take. Let's also get Bernard or the NF team to review this.